前言

成為主管職後，第一個明顯的改變就是寫 code 時間急遽減少，一部份是因為多了管理的任務，另一部份就是多了很多會議要開。

開會本身沒有很難，只要一群人聚在一起，討論一個議題，得出某個結論，好像就可以了!?

但有待過不同公司，甚至只要是不同團隊就會發現，每個團隊的會議都略有不同，有些有 timer 有會議記錄，而有些則是人直接走過來跟你說聲 「現在有空開個會嗎？」

也正是因為透過很多種方式都可以達成開會的目的，所以反而沒有一個方式可以去「評量」一場會議的好壞，導致許多會議雖然有得出結論，但曠日廢時。

難題

如果你覺得某場會議浪費時間，那大概有以下幾種情形：

1. 前情提要：如果參與者沒有準備，就會需要在會議開始 5~10 分鐘簡介一下「為什麼要開這個會」。最怕的是，都已經花時間前情提要了，有人還可能要討論「為什麼有這個前情」。

   比如開完第一場會得到結論，打算明天第二場會討論相關事項，結果我到第二場會，才想要推翻前次會議結論

2. 過多的參與者：人多反而不會積極參與討論，會覺得「人這麼多應該不用我來想吧？」，最後得出來的結論其實不是共識。

   比如人很多的會議，大家都很有想法，我不發言應該沒差吧？結果會後要執行的時候，認真思考細節才發現，我其實很多地方不同意。

3. 會議主軸不明確：通常是因為缺乏明確的目標，參與者如果不知道會議的目的是什麼，就會有很多支線討論或神來一筆，打亂會議節奏。

   比如討論經費申請，想得到的結果是明確的經費申請流程，如果沒有跟大家同步會議主軸，很容易會討論到「哪些經費可以申請」、「公司是否願意補助社團」等，慢慢偏題出去。

4. 沒有時間限制：時間愈多，反而討論出來的成果愈發散，或者容易鑽牛角尖，而且參與者會隨著時間愈來愈累，更難討論出好結論。

   比如討論員工旅遊，沒有規定時間也沒 timer，很容易一開始先花很多時間確定旅遊地點，然後討論交通方式的時候就大家腦力耗竭。

5. 沒有明確的行動項目：如果會議無法確定具體的行動項目、負責人和時間表，討論可能不會轉化為實際行動，等到忘記了又要再開一次同樣的會議。

   比如大家在會議中一致覺得知識共享很棒，決定要成立讀書會，但沒有指派人，導致 A 覺得 B 會做，B 覺得 C 會做，最後大家都沒做，過兩個月被上級盯了，又再開一次同樣的會議

策略

雖然沒有方式可以幫會議「評分」(比如: 這場會議很棒價值98分)，但有許多良好的習慣或制度，可以幫助提升會議的效率，從會議前、會議中到會議後都可以應用。

如果真的需要評分量化，或許可以計算以下這些好習慣的達成率有多高。

會議前

• 明確目標：在召開會議之前，確保明確了解會議的目標和預期結果，有助於確保會議的焦點和效率。

  目標最好是一個可以明確說出「是否達成」的描述。

• 制定議程：議程列出會議討論的主題和安排，並包含每個主題的討論時間。

  讓每個人預先知道有多少時間，埋入心中，開會時會更加專心

• 確定參與者：僅邀請必要的人參加會議，確保每個參與者都對會議主題有興趣或有關聯。

  如果考量到每個參與者的時薪，就會知道不該把所有人都抓來開會

• 提前通知：提前通知與會者會議的時間、地點、議程和任何預先準備工作，確保每個人都準備充分。

  最糟的就是人直接走過來說聲「現在有空開個會嗎？」

會議中

• 遵循議程：在會議中嚴格遵守議程，確保討論不偏離主題。

  會議主持人要硬起來！靈光一閃是難免的，但可以先記錄下來，另外開一場會議來討論

• 時間管理：管理好每個議題的時間，以確保每個主題都有足夠的時間進行討論，避免浪費時間。

  愈有限的時間，才愈會針對重點討論。
  試想員工旅遊會議只剩下 5 分鐘，該討論「如何找到合適的遊覽車司機」，還是「每個與會者的工作項目」？

• 鼓勵參與：鼓勵參與者發言，尤其是那些若有所思、眉頭緊皺的人，以及利害關係人。

  有些成員偏內向，不願意在大家咭哩括啦的時候提出自己的看法，就需要特別 cue 一下

• 記錄重點與下一步：有人可以負責記錄會議的重點摘要和行動項目。

  在會議結束前可以再跟大家 recap 一下，會議結論與每個人負責的項目。

會議後

• 發送會議記錄：盡快發送會議紀錄給與會者，確保每個人都明確了解討論內容、行動項目和下一步的步驟。
• 追蹤行動項目：監控和追蹤會議中確定的行動項目的進展，確保它們及時執行。
• 評估會議效率：定期評估會議的效率，並根據反饋不斷改進會議流程。
• 累積知識：將會議的結果和決策累積到組織的知識庫中，以便日後參考和使用。
• 反思和改進：定期反思會議，探討如何改進會議的效率和價值。

結語

我個人認為，會議「前」 做的準備，是提升整場會議效率最重要的一步。

其實就跟寫 code 一樣，寫程式碼之前要先思考架構，考慮會遇到什麼問題，並畫出設計圖。

如果說是 80/20 法則的話，那 80% 的時間都拿來做「寫 code 前準備」是比較明智的，畢竟，雪球從山頂滾下來，角度只要偏離1度，滾到山下可能就差幾百公尺了。

同樣的道理，如果開會前的準備不夠充分，很容易就導致會議結果不如預期。